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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

transferee: party being transferred to the transfer target 

transferor: party initiating the transfer 

transfer target: party that the existing communication is transferred to 

NOTE: After transfer the transferee and the transfer target are in communication with each other. 
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ECT Session Identifier URI: PSI created and inserted by a ECT AS that resolves to the AS itself 

NOTE: If this URI contains correlation information it shall not reveal identity information about any party 
involved in the transfer. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

3GPP 3"* Generation Partnership Project (www.3gpp.org) 

ACR Anonymous Communication Rejection 

AS SIP Application Server 

BGCF Border Gateway Control Function 

CDIV Communication Diversion 

CONF CONFerence 

CSCF Call Session Control Function 

ECT Explicit Communication transfer 

GRUU Globally Routable User agent URI 

HOLD communication HOLD 

IBCF Interconnect Border Control Function 

I-CSCF Interrogating-CSCF 

IETF Internet Engineering Task Force 

IFC Initial Filter Criteria 

IMS IP Multimedia Subsystem 

ISDN Integrated Services Digital Network 

MCID Malicious Call IDentification 

MGCF Media Gateway Control Function 

OCB Outgoing Communication Barring 

OIP Originating Identification Presentation 

OIR Originating Identification presentation Restriction 

P-CSCF Proxy-CSCF 

PSTN PubUc Switch Telephone Network 

S-CSCF Serving-CSCF 

SIP Session Initiation Protocol 

TIP Terminating Identification Presentation 

TIR Terminating Identification presentation Restriction 

UE User Equipment 



Explicit Communication Transfer (ECT) 



4.1 



Introduction 



The service provides a party involved in a communication to transfer that communication to a third party. 

4.2 Description 
4.2.1 General description 

The Explicit Communication transfer (ECT) service provides a party involved in a communication to transfer that 
communication to a third party. 

There are three actors active in a transfer, they are acting in the following roles: transferor, the party that initiates the 
transfer of the active communication that it has with the transferee, transferee, the party which stays in the 
communication which is transferred, transfer target, the party which the communication is transferred to and which 
replaces the transferor in the communication. 
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Assumption is that initially the transferee and the transferor are involved in a communication. In the present document 
the party that originated the original communication before transfer is tagged with UE-A, the party that terminated the 
original communication before transfer is tagged UE-B. The party that is newly introduced into communication with the 
transferee, e.g. the transfer Target is tagged UE-C. 

There are two initial situations possible in which transfer shall be possible: 

• The transferor has no ongoing communication with the transfer Target. (Blind/Assured transfer). 

• The transferor has a (consultation) communication with the transfer Target. (Consultative transfer). 

The transferor AS takes care that it remains in the signalling path even after the communication is transferred, this 
allows: 

• Classical charging models. 

• Anonimization of the transfer Target. 



4.3 Operational requirements 



4.3.1 Provision/withdrawal 

The ECT service may be provided after prior arrangement with the service provider or be generally available. 

4.3.2 Requirements on the transferor network side 

No specific requirements are needed in the network. 

4.3.3 Requirements on tine transferee network side 

No specific requirements are needed in the network. 

4.3.4 Requirements on tine transfer target network side 

No specific requirements are needed in the network. 

4.4 Coding requirements 

A user agent that wishes to use the ECT service (to act as a transferor): 

• Shall support the REFER method as a client as specified in RFC 3515 [2]. 

• Shall support the Referred-By header as specified in RFC 3892 [3]. 

• Shall support Replaces header field as specified in RFC 3891 [4]. 

A user agent that is the transferred party in a communication transfer (acts as the transferee): 

• Shall support the REFER method as a server as specified in RFC 3515 [2]. 

• Shall support the Referred-By header as specified in RFC 3892 [3]. 

• Shall support Replaces header field as specified in RFC 3891 [4]. 

A user agent that is the transfer target in a communication transfer (acting as the transferror): 

• May support the Referred-By header as a client as specified in RFC 3892 [3]. 

• May support the Replaces header as a client as specified in RFC 3891 [4]. 



£75/ 



9 ETSI TS 183 029 V1 .1 .1 (2006-04) 

4.5 Signalling requirements 

4.5.1 Activation/deactivation/registration 

Not applicable. 

4.5.2 Invocation and operation 

4.5.2.1 Actions at the transferor UE 

A UE that initiates a transfer operation, shall: 

• Issue a REFER request in the original communications dialog, where: 

The request URI shall contain the SIP URI of the transferee as received in the Contact header field. 

The Refer-To header field shall indicate the public address of the transfer Target. 

If the transferor UE has a (consultation) communication with the transfer Target, a Replaces header field 
parameter shall be added to the Refer-To URI together with a Require=replaces header field parameter. 

The Referred-By header field may indicate the identity of the transferor. 

After the REFER request is accepted by the other end with a 202 (Accepted) response, the transferor UE should get 
notifications of how the transferee's communication setup towards the transfer Target is progressing. 

When a NOTIFY request is received on the REFER dialog that indicates that the transferee and the transfer Target have 
successfully setup a communication, the transferor UE may terminate the original communication with the transferee 
UE, by sending a BYE message on the original dialog. 

4.5.2.2 Actions at the transferor P-CSCF 

Basic communication procedures according to ES 283 003 [1] shall apply. 

4.5.2.3 Actions at the transferor S-CSCF 

Basic communication procedures according to ES 283 003 [1] shall apply. 

4.5.2.4 Actions at the transferor AS 
4.5.2.4.1 Invocation of ECT service 

4.5.2.4.1 .1 Prerequisite for invocation of tine ECT service 

For ECT to be provided to end users acting as transferor, the end user's AS providing ECT shall be in the signalling 
path for all communications. 

4.5.2.4.1 .2 Determine winetlner tine ECT applies 

The transferor AS is the one executing the ECT service logic, which is invoked by the transferor sending a special 
REFER request. 

4.5.2.4.1 .2.1 REFER request received on a separate dialog 

ECT does not apply in this case. 

NOTE: That transfer could be initiated by REFER request on a separate dialog when the network supports 

GRUU. Since this is currently not specified in ES 283 003 [1], REFER on separate dialogs can not be 
used for transfer of communication. 
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4.5.2.4.1 .2.2 REFER request received in the to be transferred dialog 

In order to know whether ECT service appHes on a REFER request send by the served user, the following criteria shall 
apply before the ECT logic is executed: 

• The REFER request's request-URI (transferee) is targeted at the same UE instance that is involved in the 
dialog. 

• The REFER request's Refer-To header contains a URI so that the method constructed from the URI according 
to RFC 3261 [6] is equal to INVITE. 

Any REFER request that does not comply with these criteria shall not invoke the ECT service and is depending on 
operator policy: 

• Rejected. 

• Handled by another service. 

• Proxied on. 

4.5.2.4.1 .2.3 Actions of ECT winen invoked witin a transfer request 

When a REFER request is received that invokes the ECT service (see clause 4.5.2.4. 1), ECT service shall perform the 
following actions: 

1) Create a new ECT Session Identifier URI addressed to this AS. The URI shall be created in such a way that a 
new dialog set up towards this URI can be easily correlated with the current REFER dialog. 

2) The AS stores the value of the Refer-To header field (transfer Target) from the REFER request and links it to 
the ECT Session Identifier URI. 

3) The AS Replaces the Refer-To header field with the ECT Session Identifier URI. (This ensures that the 
transferor AS remains in the loop when the transferee sets up the communication with the transfer Target.). 

4) If a Referred-By header is available in the request, the AS verifies if the provided Referred-By header contains 
a valid identity of the served user. If not it will replace the Referred-By header with a valid value matching the 
REFER request's P-Asserted-Identity. 

5) If no Referred-By header is available in the request a Referred-By header is added that matches the REFER 
method's P-Asserted-Identity. 

6) The AS sends the REFER request on to the transferee using basic communication procedures ES 283 003 [1]. 

4.5.2.4.2 Subsequent procedures 

4.5.2.4.2.1 Actions of ECT winen invoked again by tine transferred communication 

When an INVITE is received targeted at the ECT Session Identifier URI created earlier when the served user requested 
transfer of an ongoing communication, ECT shall perform the following actions: 

1) Replace the request URI with the stored transfer Target URI linked to the specific ECT Session Identifier URI. 

2) If a Referred-By header is available in the request, the AS verifies if the provided Referred-By header contains 
a valid identity of the served user. If not it will replace the Referred-By header with a valid value matching the 
REFER request's P-Asserted-Identity. 

3) If no Referred-By header is available in the request a Referred-By header is added that matches the REFER 
request's P-Asserted-Identity. 

NOTE: If needed the AS may generate charging events to charge for the extra leg. 

4) The INVITE request is forwarded towards the transfer Target using basic communication procedures 
ES 283 003 [1]. 



£75/ 



11 ETSI TS 183 029 V1.1.1 (2006-04) 

4.5.2.5 Actions at the transferee UE 

Normal REFER handling procedures according to ES 283 003 [1] shall apply. 

4.5.2.6 Actions at the transferee S-CSCF 

Basic communication procedures according to ES 283 003 [1] shall apply. 

4.5.2.7 Actions at the transferee AS 

4.5.2.7.1 Determine whether the ECT applies 

See clause 4.5.2.4.1 on the criteria that determine that a REFER request is to be treated as a request for transfer of an 
existing communication. 

4.5.2.7.2 Actions of ECT when involved with a transfer request 

When a REFER request is received in the context of a call transfer scenario (see clause 4.5.2.4.1), it shall perform the 
following steps: 

1) Store the value of the Refer-To header field (used later to correlate the new communication with this REFER 
dialog. 

2) Forward the request to the transferee according to basic communication procedures ES 283 003 [1]. 

4.5.2.7.3 Actions of ECT when invoked again by the transferred communication 

When an INVITE is received targeted at the SIP URI stored earlier when a transfer request was received targeted at the 
served user (transferee), ECT shall perform the following actions: 

1) Optionally the AS may generate charging events: 

a) To charge for the original communication between the transferee and the transferor, in case the transferee 
was the originating party in the original communication. 

b) To switch of charging in case the transferee was the terminating party in the original communication. 

2) The INVITE is forwarded towards the transfer Target using basic communication procedures ES 283 003 [1]. 

4.5.2.8 Void 

4.5.2.9 Actions at the incoming l-CSCF 

Basic communication procedures according to ES 283 003 [1] shall apply. 

4.5.2.1 Actions at the outgoing IBCF 

Basic communication procedures according to ES 283 003 [1] shall apply. 

4.5.2.1 1 Actions at the incoming IBCF 

Basic communication procedures according to ES 283 003 [1] shall apply. 

4.5.2.1 2 Actions at the BGCF 

Basic communication procedures according to ES 283 003 [1] shall apply. 

4.5.2.1 3 Actions at the IVIGCF 

Basic communication procedures according to ES 283 003 [1] and ES 283 027 [5] shall apply. 
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Upon reception of a REFER request the MGCF generates a 403 Forbidden response. See ES 283 027 [5]. 

4.5.2.14 Actions at the transfer target's S-CSCF 

Basic communication procedures according to ES 283 003 [1] shall apply. 

4.5.2.1 5 Actions at the transfer target's AS 

Basic communication procedures according to ES 283 003 [1] shall apply. 

4.5.2.16 Actions at the transfer target's P-CSCF 

Basic communication procedures according to ES 283 003 [1] shall apply. 

4.5.2.1 7 Actions at the transfer target's UE 

Basic communication procedures according to ES 283 003 [1] shall apply. 

4.6 Interaction with other services 

4.6.1 Communication HOLD (HOLD) 

No impact. 

4.6.2 Terminating Identification Presentation (TIP) 

No impact. 

4.6.3 Terminating Identification Restriction (TIR) 

Transferor AS: 

• TIR privacy settings shall be enforced on the Referred-By header carried in INVITE. 

4.6.4 Originating Identification Presentation (OIP) 

No impact. 

4.6.5 Originating Identification Restriction (OIR) 

For the transferor AS the following applies: 

• OIR privacy settings shall be enforced on the Referred-By header carried in REFER request. 

• For the other transferee AS and the transfer Target AS there is no impact. 

4.6.6 CONFerence Calling (CONF) 

No impact. 

4.6.7 Communication Diversion Services (CDIV) 

No impact. 
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4.6.8 Malicious Communication IDentification (MCID) 

No impact. 

4.6.9 Anonymous Communication Rejection and Communication Barring 
(ACR/CB) 

For the transferor AS the following applies: 

• Shall not accept transfer requests with a transfer Target that is barred by the served users Outgoing 
Communication Barring (OCB) rules. 

• For the transferee AS and the transfer Target AS there is no impact. 

4.7 Interactions with other networks 

4.7.1 Interaction with PSTN/ISDN 

Interaction with PSTN/ISDN is defined in ES 283 027 [5]. 

4.7.2 Interaction with PSTN/ISDN Emulation 

No impact. 

4.7.3 Interaction with external IP Network 

Interaction with external IP networks are performed according to ES 283 003 [1]. 

4.8 Parameter values (timers) 

No specific timers are required. 

4.9 Service configuration 

Not applicable. 
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Annex A (informative): 
Signalling flows 

A.1 Blind transfer 

Figure A. 1 signalling flow shows a blind transfer scenario, whereby the REFER request is sent on the existing INVITE 
dialog between A and B. 



Transferror 
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UE-A 
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(P-CSCF, 

l-CSCF, S-CSCF, 

AS) 



AS-B 

(P^CSCF. 
l-CSCF, S- 
CSCF, AS) 



UE-B 



AS-C 

(P-CSCF, 
l-CSCF, S- 
CSCF, AS) 



dialog 1; 

INVITE usage 



Media streams have been setup between A and B, AS-A and AS-B are in tine 
signalling path. See "Basic Cali" procedure. 



B puts A on hold, see "Session Hold/Resume" Procedure 



Media between A and B are on Hold 




This allows B to 
pick up the 
existing session 



dialog 1; 
REFER usage 



dialog 1; 

INVITE usage 
terminates 
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■ private-URL . 
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Media between A and B are Terminated 
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Figure A.I : Blind transfer 



ETSI 



15 ETSI TS 183 029 V1.1.1 (2006-04) 

1. A multimedia session exists between A-B. B initiates transfer A to C, by sending REFER request 
To: UE-A with Referred-To: UE-C, Referred-By: UE-B. The REFER request is send in the 
existing dialog that between A and B. 

1 . 1 Upon reception of the REFER request, AS-B should check whether there is no outgoing call 

barring active from B to C. Because B is charged for the call from B-C when A is referred to C, 
when outgoing call barring is active from B-C the REFER request shall be rejected. 

AS-B checks whether B is allowed to transfer calls, if it is allowed to transfer the call then AS-B generates a ECT 
Session Identifier URI , addressed to itself, with the new destination information and billing information that will be 
needed for the new session. It replaces the Refer-To value with the ECT Session Identifier URI. This ensures that: 

AS-B will remain in the loop 

2. The REFER request is sent on to AS -A. 

2.1 AS-A checks whether it is allowed to transfer A.. 

3. The REFER request is sent on to A by AS-A. 

4. The REFER request is accepted by A's UE. 

4.1, 7.1, 31.1 AS-A can use result messages and notifications caused by the REFER request to track success of 
refer and take appropriate actions. The AS should ensure that header fields that where replaced 
with other content are recreated with the original content on the way back. 

5.1, 8.1, 32.1 AS-B can use this to track success of the REFER request and take appropriate actions. The AS 
should ensure that header fields that where replaced with other content are recreated with the 
original content on the way back. 

7. Since the REFER request was accepted in 6. UE-B terminates the existing INVITE dialog by 

sending a BYE to UE-A. 

19. The UE-A initiates a new session by sending an INVITE request to AS-B's ECT Session Identifier 

URI (which represents UE-C). 

19. 1 AS-A routes the INVITE request to AS-B using the AS-B's ECT Session Identifier URI using 

normal SIP routing procedures. Normal charging from A to B applies. 

20. 1 Upon receiving the INVITE request to the ECT Session Identifier URI that was inserted by the 

B-AS, the B-AS replaces it with the Request URI of C and creates an INVITE targeted towards 
UE-C. 

In this scenario it can be assumed that there is no active outgoing call barring towards UE-C, because the REFER was 
accepted by AS-B. The ECT Session Identifier URI should have a limited validity time to ensure that no future barring 
are violated For now it is assumed that this is enough. 

Also the Referred-By: header field is verified or filled in with the original uncodified values. Then the INVITE request 
is forwarded to UE-C using normal routing procedures. 

21.1, 23.1 Normal terminating services apply for UE-C. The call shall be treated as a call from A-C regarding 

call policies. 

25.1 AS-A. Normal response handling applies. 

27. 1 AS-A. Normal ACK handhng appHes. 

28.1 AS-B replaces all codified values and ECT Session Identifier URI 's with stored values. 
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A.2 Consultative transfer 



Figure A.2 signalling flow shows a consultative transfer scenario: 
Transferror Transferee 



Transfer Target 



UE-A 



dialog 1 

INVITE usage 






dialog 2 





I 



AS-A 

(P-CSCF, 

l-CSCF, S-CSCF, 

AS) 



I 



AS-B 

(P-CSCF, 
l-CSCF, S- 
CSCF, AS) 



UE-B 



Media streams have been setup between A and B, AS-A and AS-B are in tiie 

signaiiing path. See "Basic Call" procedure. 
::::x:::::::::::::::::::::::::::::::j:::::::::::::::::::::::::::::::j:::::::::^^ 

B puts A on hold, see "Session Hold/Resume" Procedure 

Media between A and B are on Hold 



dialog 1 

REFER usage 



dialog 1 

REFER usage 



dialog 3 



dialog 3 



AS-B stores the "Refer-To" and 
"Referred-By" information and 
replaces it with ECT Session 
Identifier URIs, so that UE-A will no1 
know the identity of UE-B or UE-C 
and the AS-B is kept in the route. 





B uses standard "Basic Call" procedure to setup a call with C 

Media streams between B and C ^^^^ 



3. REFER 



4. 202 Accepted 



2. REFER Refer-To: 
private-URL , 



B puts C on hold, see "Session Hold/Resume" Procedure 

::::::::::::::::::: ::::r::::::::::::::::::::::::::::::r 

Media streams between B and C are on Hold 



7. NOTIFY(IOOTrvinfl) 



5. 202 Accepted 



12. 200 OK 



13. INVITE 

To: private URL 

Replaces: dialog ^ 



100 Trying 



8. NOTIFY(IOOTrying) 



20. 200 OK 



100 Trying 




100 Trying 



17. 200 OK 



dialog 2 



dialog 1 

REFER usage 



dialog 1 

INVITE usage 




Figure A.2: Consultative transfer 
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1. A multimedia session exists between A-B and between B-C. B initiates transfer A to C, by sending 
REFER method To: UE-A GRUU with the Referred-To: UE-C?Replaces=dialog2, Referred-By: 
UE-B. The REFER reuses the dialog that exists from A-B. 

1 . 1 Upon reception of the REFER operation AS-B should check whether there is no outgoing call 

barring active from B to C. Because B is charged for the call from B-C when A is referred to C, 
when outgoing call barring is active from B-C the REFER is rejected. 

AS-B checks whether B is allowed to transfer calls, if it is allowed to transfer the call then AS-B generates a ECT 
Session Identifier URI, addressed to itself, with the new destination information and billing information that will be 
needed for the new session. It replaces the Refer-To value with the ECT Session Identifier URI. This ensures that AS-B 
will remain in the loop 

2. The REFER to method is sent on to AS-A. 

2. 1 AS-A checks whether it is allowed to transfer A. 

3. Refer is sent on to A by AS-A. 

4.1, 7.1, 31.1 AS-A can use result messages and notifications caused by REFER to track success of REFER and 
take appropriate actions. The AS should ensure that header fields that where replaced with other 
content are recreated with the original content on the way back. 

5. 1, 8. 1, 32. 1 AS-B can use this to track success of REFER and take appropriate actions. The AS should ensure 
that header fields that where replaced with other content are recreated with the original content on 
the way back. 

13. he UE-A initiates a new session by sending an INVITE to AS-B's ECT Session Identifier URI 

(which represents UE-C). And inserts a Replaces: header field that will allow the new session to 
take the place of the existing session between B and C. 

13.1 AS-A checks whether A is allowed to use the Replace extension and routes the INVITE to AS-B 

using the AS-B's ECT Session Identifier URI using normal SIP routing procedures. Normal 
charging from A to B applies. 

14. 1 Upon receiving the INVITE to the ECT Session Identifier URI that was inserted by the B-AS, the 

B-AS replaces the Request URI and creates an INVITE targeted towards UE-C's. 

In this scenario it can be assumed that there is no active outgoing call barring towards UE-C, because UE-B was able to 
setup a call to UE-C in the first place. However when there was no consultation call to UE-C, there is an issue but this 
should be solved at the initial reception of the REFER from UE-C and not at this stage. 

Also the Referred-By: and Replaces: header field are filled in with the original uncodified values. Then the INVITE is 
forwarded to UE-C using normal routing procedures. 

15.1, 17.1 Normal terminating services apply for UE-C. The call shall be treated as a call from A-C regarding call 
policies. AS-C checks whether the Replace mechanism may be used. 

19.1 AS-A. Normal response handling applies. 

21.1 AS-A. Normal ACK handling appUes . 

22.1 AS-B replaces all codified values and the ECT Session Identifier URI with stored values. 

25. UE-C terminates dialog 2 as consequence of normal Replace procedures. RFC 3891 [4]. 
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Annex B (informative): 
Example of filter criteria 

B.1 Example of filter criteria for ECT 

This Annex provides an example of a filter criterion that triggers SIP requests that are subject to initial filter criteria 
evaluation. 

When the initial request matches the conditions of the next unexecuted IFC rule for the served user which points to the 
ECT service, the communication is forwarded to the AS. 

An example of an Initial Filter Criteria (IFC) Trigger Point configurations under the assumption that the ECT service is 
a standalone service that can be invoked by a very specific triggerpoint active at the destination S-CSCF: 

• Method='TNVITE" 

NOTE 1: The coding of the Initial Filter Criteria is described in TS 183 033 [7]. 

NOTE 2: Note that when the REFER is sent on an existing dialog, no IFC processing will be performed, because 
this is a subsequent request on an existing dialog. It follows that when this scenario should be supported, 
that then all signalling shall be traversed through the AS. 
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Annex C (informative): 
Example charging model 

C.1 Example of B REFER's A to C 

This scenario is added to show that the solution presented in the present document is able to support classical charging 
models. Assumption in this scenario is that A originated the original call and is thus charged for the initial A-B 
communication. 



B REFERS A TO C 



correl. 
ncorrel. with 
xwith ECT 

:-Session 
Diakjg Identifier 



correl. 
correl. witli 
witti ECT 

Target- Session 
Dialog Identifier 




A->B: INVITE/OK A:A-B 



B->A: REFER 



A->C: INVITE 



Figure C.1 : Example of B REFER's A to C 
Table C.1 



Initial Session Initiated By 


Initial Session A-B 


Transferred Session 
Transfer Targe tC 


A=Transferee 


Transferee (A): A-B 


Transferee (A): A-B 
Transferror (B): B-C 


A=Transferror 


Transferror (A): A-B 


Transferror (A): A-B 
Transferror (A): A-C 
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C.2 Example of A REFER's B to C 

This scenario is added to show that the solution presented in the present document is able to support classical charging 
models. Assumption in this scenario is that A originated the original call and is thus charged for initial A-B 
communication. 



A REFERS BTOC 



correl. 
correl. with 



Irrel. 
correl. with 
with ECT 
Target- Session 
Dialog Identifier 
— ■ — --URJ-- 
I A$-B 

mm [or 
a 





;scF- 
c 



2. 

3. 



A->B: INVITE/OK A:A-B 
A->B: REFER 
B->C: INVITE 

Figure C.2: Example of a REFER's B to C 
Table C.2 



Transfer Target 




Initial Session Initiated By 


Initial Session A-B 


Transferred Session 
Transfer Target C 


A=Transferee 


Transferee (A): A-B 


Transferee (A): A-B 
Transferror (B): B-C 


A=Transferror 


Transferror (A): A-B 


Transferror (A): A-B 
Transferror (A): A-C 
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